-
Enhancement
-
Resolution: Not an Issue
-
P5
-
None
-
5.0
-
x86
-
linux
A DESCRIPTION OF THE REQUEST :
There is no blocking version of peek() in BlockingQueue, which means it is impossible to poll the head of the queue efficiently without retrieving the head item (via poll() or take()).
JUSTIFICATION :
A blocking version of peek() is required in order to allow implementations of BlockingQueue which provide queue persistence or guaranteed delivery. For the latter, a two-stage peek()/take() process is required to ensure that the consumer has completely processed the object before it is removed from the queue.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
public interface BlockingQueue<E> {
...
public E peek(boolean blockIfEmpty);
public E peek(boolean blockIfEmpty, long timeout, TimeUnit unit);
...
}
CUSTOMER SUBMITTED WORKAROUND :
A possible solution is to change the locking structures in LinkedBlockingQueue and its counterparts to be protected rather than private, to allow subclasses to implement this functionality.
There is no blocking version of peek() in BlockingQueue, which means it is impossible to poll the head of the queue efficiently without retrieving the head item (via poll() or take()).
JUSTIFICATION :
A blocking version of peek() is required in order to allow implementations of BlockingQueue which provide queue persistence or guaranteed delivery. For the latter, a two-stage peek()/take() process is required to ensure that the consumer has completely processed the object before it is removed from the queue.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
public interface BlockingQueue<E> {
...
public E peek(boolean blockIfEmpty);
public E peek(boolean blockIfEmpty, long timeout, TimeUnit unit);
...
}
CUSTOMER SUBMITTED WORKAROUND :
A possible solution is to change the locking structures in LinkedBlockingQueue and its counterparts to be protected rather than private, to allow subclasses to implement this functionality.